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Amendments to the Drawings 

Submitted herewith are 21 sheets of formal drawings including Figs. 1-21, 
labeled Replacement Sheets, which are to replace the original 21 sheets of drawings 
including Figs. 1-21 . Entry of these replacement drawings is respectfully requested. 
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REMARKS 

By this amendment, claims 19-31 are added and claims 7 and 16 are amended 
to be in independent form. As a result, claims 1, 7, 8, 9, 16 and 18 are independent 
claims. Applicants submit herewith the fee for the consideration of 1 1 extra total 
claims and two extra independent claims over the 20 total and four independent 
claims for which examination fees have been previously paid. Moreover, this paper is 
timely filed as it is submitted with a certificate of mailing under 37 C.F.R. §1.8, a 
petition for a one-month extension of time, and a check for the required petition fee 
under 37 C.F.R. § 1.17(a)(1) thereby extending the response date to December 24, 
2006. 

I. OBJECTIONS TO THE ABSTRACT AND DRAWINGS 

Applicants respectfully traverse the objections to the abstract and the 
drawings. Applicants have amended the abstract to be less than 150 words. 
Applicants also include herewith a set of replacement drawings which have been 
formalized to overcome the deficiencies noted by in the Notice of Draftsperson's 
Patent Drawing Review attached to the action dated December 24, 2002. Withdrawal 
of the objections to the abstract and the drawings is hereby respectfully requested. 

II. REJECTIONS UNDER 35 U.S.C. §101 

Applicants respectfully traverse the rejections of claims 8-17 as being directed 
to non-statutory subject matter. These claims have been amended to recite specific 
structure in the form of a user interface system having a computer processor. As a 
result, these claims are now clearly drawn to patentable subject matter under 35 
U.S.C. §101. Applicants therefore respectfully request reconsideration and 
withdrawal of these rejections. 

III. REJECTIONS UNDER 35 U.S.C. §103 

Applicants respectfully traverse the rejections of claims 1-6, 8, 12-15 and 18 
as obvious over Rosenof ("Data Logging and Reporting for Effective Batch Control"). 
Reconsideration and withdrawal of these rejections are respectfully requested in light 
of the remarks provided below. In response to the Examiner's comments in the 
Office Action, each of these claims is amended to more clearly indicate that the 
recited system automatically derives relationships among portions of process event 
information and batch subprocedure event information to thereby associate particular 
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process event information with one or more particular batch subprocedures. Thus, the 
recited system now clearly indicates that it derives relationships between process 
event information and batch subprocedure information to establish a particular batch 
subprocedure with which a particular process event is associated. 

As recognized by the examiner, Rosenof does not disclose a system that 
associates process event information (e.g., device alarms, device alerts, etc.) with 
particular batch subprocedures, such as phases, etc. of a batch run. Instead, at best, 
the Rosenof system is limited to collecting process event information (to the extent 
the Rosenof system performs this step at all) on a batch by batch basis and storing the 
process event information for a particular batch in a single file that is separate from a 
file in which batch procedure event information is located. While these files may be 
printed out separately, at no point does Rosenof describe or suggest establishing 
relationships between batch procedure information and process event information 
stored within separate files. Thus, Rosenof cannot suggest deriving relationships 
between process event information and batch subprocedure event information "to 
thereby associate particular process event information with one or more particular 
batch subprocedures" as is recited by each of claims 1-6, 8, 12-15 and 18. 

Generally speaking, each of claims 1-6, 8, 12-15 and 18 recites an event 
historian, a batch history view application or a batch history viewer that is used in a 
batch process to collect (1) process event information comprising batch process data 
related to the operation of the process equipment within a process plant (e.g., the 
valves, tanks, etc. that are actually performing the batch process) and (2) batch 
procedure event information, including batch subprocedure event information, from a 
batch control device (e.g., the process controller that controls the process equipment 
to perform the batch process). Importantly, the recited event historian or the viewing 
device derives relationships between the batch procedure event information (including 
one or more batch subprocedures which make up a batch procedure) and the process 
event information to thereby be able to display the batch process data in a manner that 
illustrates how the batch process data (e.g., device alarms, measurements, etc.) relate 
to the particular batch subprocedures being performed (such as which batch 
subprocedure was being performed when a particular device alarm arose). In this 
manner, a user may view or be able to easily determine what batch subprocedure was 
taking place when a particular piece of process equipment failed, sent an alarm or 
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other notification, experienced a particular process condition, etc. This ability to view 
the batch process data (e.g., process equipment alerts and alarms) in a manner that is 
coordinated with or that identifies the batch subprocedure being implemented by the 
controller on the equipment at the time, aids operators and other users to better 
diagnose problems or to better understand the operation of the batch process. 

Rosenof simply fails to disclose or suggest deriving relationships between 
batch subprocedure event information collected from a batch process controller and 
process event information collected from various process devices implementing the 
batch process, such as valves, sensors, etc. As a result, Rosenof fails to render any of 
claims 1-6, 8, 12-15 or 18 obvious. In particular, the examiner indicates that it would 
have been obvious to one of ordinary skill in the art to recognize "that the claimed 
limitation only mentioned that the batch procedure event information includes batch 
sub-procedure event information" and that, therefore, "one of the scenarios the batch 
procedure event information could be batch sub-procedure event information itself." 
See, Office Action dated August 24, 2006, paragraph 11, pgs 4-5. Even if this 
statement is assumed to be true, claims 1-6, 8, 12-15 and 18 now specifically indicate 
that the recited system derives relationships between process event information and 
batch subprocedures to thereby associate particular process event information with 
one or more particular batch subprocedures. As will be recognized, Rosenof does not, 
in any way, suggest that it is desirable or even possible to associate process event data 
with particular batch subprocedures. As a result, there is no suggestion or motivation 
within Rosenof to change Rosenof to be a system, like the claimed system, that 
associates particular process event data with particular batch subprocedures. 

Furthermore, Applicants submit that the Examiner has not established how 
Rosenof stores process event data in the first place, nor how process event data is 
associated with batch procedure data in any manner. First of all, it is not clear that 
Rosenof discloses storing process event data in any separate log file. While Rosenof 
clearly collects data from the batch process, Rosenof does not specifically say it 
collects or stores process event data. However, even assuming that the Rosenof 
system collects and store process event data from various process control devices, the 
Examiner has still failed to show how, in any manner, Rosenof "automatically derives 
relationships among portions of said process event information and batch procedure 
event information." While the Examiner points to Figs. 5 and 6 and states that "an 
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event log signals various stages of the process which are then displayed graphically to 
a user in a relation to the ideal 'scheduled' performance" (see Office Action dated 
August 24, 2006, paragraph 10, pages 3-4), the Examiner does not explain how this 
statement amounts to associating process event information, such as data collected 
from individual process devices like field devices, with batch procedure event 
information, such as information regarding the various phases within a batch. In 
particular, as explained previously, Fig. 5 discloses an event log that stores particular 
batch procedure events, such as the start of the batch, the adding of the reactant, the 
taking of the temperature, all of which are events specified by a recipe that the batch 
controller is implementing. Thus, at best, Fig. 5, shows a log of batch procedural 
event information. The Examiner does not explain how Fig. 5 (or Fig. 6 which is a 
graph of the data in Fig. 5) in any way includes process event information, nor how 
either Fig. 5 or Fig. 6 illustrates a relationship between process event information and 
batch procedure event information. Put another way, the Examiner has failed to 
described or in any way indicate the particular data shown in Fig. 5 or Fig. 6 that the 
Examiner is considering to be "process event information," nor what data the 
Examiner is considering to be "batch procedure event information" or any manner in 
which any relationship between these different kinds of data is developed or displayed 
in Fig. 5 or 6. 

Thus, while Rosenof appears to disclose the use of a data logging file to 
collect and store batch procedure event data from a batch control device (which data 
is indicative of milestones or dividing points defining the batch procedures) and 
possibly the use of other data logging files to collect process event data, such as 
alarms, measurements, etc. generated by, for example, field devices used to 
implement the batch process, Rosenof does not disclose or suggest deriving 
relationships between the collected batch procedure event information and the 
collected process event information in any manner, much less to "associate particular 
process event information with one or more particular batch subprocedures." Instead, 
Rosenof is similar to the prior art referred to in the "Discussion of Related Art" 
section of the application, in that Rosenof merely collects the different types of data 
(i.e., the batch procedure event information and the batch process event information) 
in different files without trying to associate these various different types of data with 
one another in order to provide for operator ease in determining, for example, the 
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batch subprocedure that was being implemented by the process controller when a 
particular process event (such as a device alarm) occurred within one of the physical 
devices being used to implement the batch procedure. 

Moreover, as indicated above, neither Fig. 5 nor Fig. 6 of Rosenof illustrates a 
relationship between these different types of data, as these figures only illustrate one 
of these types of data, i.e., biatch procedure event information. The data log of Fig. 5 
does not include any actual process event information, such as device alarms 
generated by process devices (e.g., valves, sensors, etc.) or any data collected by such 
devices. Put another way, the data file of Fig. 5 of Rosenof merely stores data 
indicating the times associated with "milestone" events of the batch procedure (see 
Rosenof, page 32, column 2, lines 9-12), which is simply another way of defining a 
specific part of a particular batch procedure. Thus, the data stored in the file of Fig. 5 
and illustrated in Fig. 6 of Rosenof relates only to batch procedure event information, 
not to process event information, which is data collected from or sent from the 
devices actually implementing the various phases of the batch procedure. 

Because Rosenof does not derive or illustrate relationships between batch 
procedure event information and process event information, the reports illustrated in 
Figs. 4-6 of Rosenof do not enable a user to see or easily determine relationships 
between batch procedure event information (e.g., data indicative of what portion or 
part of the batch is being implemented) and process event information (e.g., data 
indicative of specific measurements or alarms generated by devices implementing the 
batch procedure). Thus, as is the case with other prior art tools discussed in the 
application, the Rosenof system still requires an operator to manually derive 
relationships between the collected process event data and the collected batch 
procedure event data. 

It is clear that the prior art must make a suggestion of or provide an incentive 
for a claimed combination of elements to establish a prima facie case of obviousness. 
See, In re Oetiker, 977 F.2d 1443, 24 U.S.P.Q.2d 1443, 1446 (Fed. Cir. 1992); Ex 
parte Clapp, 227 U.S.P.Q. 972, 973 (Bd. Pat. App. 1985). Rosenof simply fails to 
provide any suggestion of or motivation for determining relationships between 
process event information and batch procedure event information, such as that of Figs. 
5 and 6 of Rosenof, much less for displaying process event information in the same 
display as batch procedure event information. In fact, it is not clear how process 
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event information could be shown in the display of Fig. 6 of Rosenof Because 
Rosenof fails to suggest or provide any manner of determining relationships between 
process event information and batch subprocedure event information, it follows that 
Rosenof does not render any of claims 1-6, 8, 12-15 or 18 obvious. 



Applicant's Interview Summary 

On August 4, 2006, Applicants' attorney, Roger A. Heppermann, conducted a 
telephonic interview with Examiner Jennifer N. To during which the above-identified 
application was discussed. During this interview, Rosenof was discussed in detail. 
However, contrary to the Examiner's indication, Applicants did not agree with the 
Examiner that Rosenof teaches to automatically derive a relationship among batches 
or at least among portions of process event information and batch procedure event 
information based on generated event messages. To the contrary, Applicants 
indicated that, to the extent that Rosenof discloses the collection of process event 
information at all, it is limited to associating that process event information with a 
particular batch at a batch level. However, Applicants agreed to amend claim 8 to 
include specific structure in order to be clearly drawn to patentable subject matter 
under 35 U.S.C. § 101 . The Applicants wish to thank Examiner To for her time 
during the interview. , 
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IV. CONCLUSION 

For the foregoing reasons, Applicants submit that this application is in 
condition for allowance. Reconsideration and withdrawal of the rejections and 
allowance of the rejected claims are therefore respectfully requested. If there are any 
additional fees or refunds required, the Commissioner is hereby authorized to charge 
or credit Deposit Account No. 13-2855 (under order number 06005/36359) from 
which the undersigned attorney is authorized to draw. 



Respectfully submitted, 



December 22, 2006 By: 



Roger A. Heppermann 
Reg. No. 37,641 

Marshall, Gerstein & Borun LLP 

6300 Sears Tower 

233 South Wacker Drive 

Chicago, Illinois 60606-6402 

(312) 474-6300 

Attorney for Applicants 
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